Недавно мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а также новой версии средства создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2. Сегодня мы немного подробнее расскажем о новых возможностях инфраструктуры работы с хранилищами (core storage) в новом обновлении vSphere.
Давайте посмотрим, что именно там нового:
1. Увеличение iSCSI Path Limit
Раньше для одного LUN максимально доступны были только 8 путей, но многим пользователям требовалось существенно больше. Используя несколько портов VMKernel или точек назначения, пользователям иногда было нужно 16 или даже 24 пути. Теперь максимум составляет 32 пути на LUN, что должно хватить всем.
2. Поддержка RDM для RHEL HA
Теперь для для работы Red Hat Enterprise HA можно использовать тома RDM на платформе vSphere. В корневых механизмах работы с хранилищами для этого были сделаны некоторые изменения.
3. Улучшения снапшотов VMFS SESparse
При чтении данных для машин со снапшотами существенно увеличилась производительность, так как чтение идет сразу из нужного VMDK, минуя всю цепочку снапшотов при каждом обращении, в отличие от того, как это было сделано раньше. Все это снижает latency на чтение.
4. Поддержка нескольких адаптеров Paravirtual RDMA (PVRDMA)
В vSphere 6.7 была анонсирована поддержка RDMA. Одним из ограничений было то, что для одной виртуальной машины можно было использовать только один адаптер PVRDMA. Теперь этой проблемы больше нет.
5. Улучшения производительности для томов VMFS
Здесь были сделаны улучшения первых операций чтения для тонких дисков. Они особенно проявляются при резервном копировании и восстановлении, операциях копирования данных и Storage vMotion.
6. Улучшения работы с NFS-хранилищами
Теперь не обязательно создавать клон ВМ для использования offload'а операций по созданию снапшотов уровня дискового массива. Теперь можно использовать любые виртуальные машины на базе снапшотов без необходимости создавать redo logs.
7. Поддержка High Performance Plugin FastPath для Fabric Devices
Плагин HPP теперь используется по умолчанию для устройств NVMe. В плагине есть 2 опции - SlowPath для legacy-поведения и новый FastPath для большей производительности, но с некоторыми ограничениями. Подробнее рассказано вот в этой статье.
8. HPP - дефолтный плагин для vSAN
Начиная с vSphere 7 Update 2, HPP теперь дефолтный MPP для всех устройств - SAS/SATA/NVMe (и Fabric Devices, как было сказано выше).
9. Улучшения VOMA
Средство vSphere On-disk Metadata Analyzer (VOMA) используется для нахождения и исправления повреждений метаданных томов, которые влияют на файловую систему и логические тома. Теперь это доступно и для spanned VMFS-томов. Более подробно об этом можно узнать тут.
10. Поддержка бОльших значений Queue Depth для vVols Protocol Endpoints
В некоторых случаях параметр Disk.SchedNumReqOutstanding (DSNRO) не соответствует глубине очереди на vVols Protocol Endpoint (PE) (он же VVolPESNRO). Теперь глубина очереди для PE равна 256 или берется максимальная глубина видимого LUN. Поэтому минимум PE QD выставлен в 256.
11. Создание Config vVol больше, чем на 4 ГБ
Теперь это позволяет партнерам VMware хранить образы для автоматических билдов на томах VVols.
12. Улучшения правил SPBM Multiple Snapshot
Движок Storage Policy Based Management позволяет администратору управлять фичами хранилищ VVols на уровне отдельных виртуальных машин. Теперь в рамках одной политики SPBM можно использовать несколько правил для снапшотов (например, интервалы их создания). Эта фича должна поддерживаться на уровне VASA у соответствующего производителя массива.
13. Поддержка снапшотов для Cloud Native Storage (CNS) на базе First Class Disks
Тома Persistent Volumes (PV) на платформе vSphere создаются как First-Class Disks (FCD). Это независимые диски без привязанных к ним ВМ. Для них теперь есть поддержка снапшотов и их можно делать в количестве до 32 штук. Это позволяет делать снапшоты ваших K8s PV на платформе vSphere Tanzu.
14. Маппинг CNS PV на vVol
В некоторых случаях пользователи хотят видеть, какие тома VVols ассоциированы с томами CNS Persistent Volume (PV). Теперь этот маппинг можно увидеть в интерфейсе CNS.
Вчера мы писали о новых возможностях обновленной платформы виртуализации VMware vSphere 7 Update 2, а сегодня расскажем о вышедшем одновременно с ней обновлении решения для создания отказоустойчивых кластеров хранилищ VMware vSAN 7 Update 2.
Нововведения сосредоточены в следующих областях:
Давайте посмотрим, что именно нового в vSAN 7 U2:
Улучшения масштабируемости
HCI Mesh Compute Clusters
Теперь в дополнение к анонсированной в vSphere 7 Update 1 топологии HCI Mesh для удаленного доступа к хранилищам vSAN появилась технология HCI Mesh Compute Clusters, которая позволяет иметь вычислительный кластер vSphere/vSAN без собственных хранилищ, использующий хранилища удаленных кластеров.
Самое интересное, что эти кластеры не нуждаются в лицензиях vSAN, вы можете использовать обычные лицензии vSphere.
Также такие кластеры vSAN могут использовать политики хранилищ, в рамках которых можно получить такие сервисы, как дедупликацию / компрессию или шифрование Data-at-rest:
Также было увеличено число хостов ESXi, которые могут соединяться с удаленным датастором, до 128.
Небольшое видео о том, как создать HCI Mesh Compute Cluster:
Улучшение файловых служб
Службы vSAN file services теперь поддерживают растянутые (stretched) кластеры и двухузловые конфигурации, что позволяет использовать их для ROBO-сценариев.
Улучшения растянутых кластеров
Растянутые кластеры vSAN теперь обрабатывают не только различные сценарии сбоев, но и условия восстановления, которые были определены механизмом DRS до наступления события отказа. DRS будет сохранять ВМ на той же площадке до того, как данные через inter-site link (ISL) будут полностью синхронизированы после восстановления кластера, после чего начнет перемещать виртуальные машины в соответствии со своими правилами. Это повышает надежность и позволяет не загружать ISL-соединение, пока оно полностью не восстановилось.
Технология vSAN over RDMA
В vSAN 7 Update 2 появилась поддержка технологии RDMA over Converged Ethernet version 2 (RCoEv2). Кластеры автоматически обнаруживают поддержку RDMA, при этом оборудование должно находиться в списке совместимости VMware Hardware Compatibility Guide.
Улучшения производительности
В vSAN 7 U2 была оптимизирована работа с RAID 5/6 в плане использования CPU. Также была улучшена производительность яруса буффера. Это позволяет снизить CPU cost per I/O.
Кроме того, были сделаны оптимизации для процессоров AMD EPYC (см. тут).
Улучшения для задач AI and Developer Ready
Здесь появилось 2 основных улучшения:
S3-совместимое объектное хранилище для задач AI/ML и приложений Cloud Native Apps.
На платформе vSAN Data Persistence platform теперь поддерживаются компоненты Cloudian HyperStore и MinIO Object Storage. Пользователи могут потреблять S3-ресурсы для своих AI/ML нагрузок без необходимости долгой настройки интеграций.
Улучшения Cloud Native Storage в vSphere и vSAN
Теперь Cloud Native Storage лучше поддерживает stateful apps на платформе Kubernetes. Также vSAN предоставляет простые средства для миграции с устаревшего vSphere Cloud Provider (vCP) на Container Storage Interface (CSI). Это позволит иметь персистентные тома Kubernetes на платформе vSphere и расширять их по мере необходимости без прерывания обслуживания.
Улучшения безопасности
Службы vSphere Native Key Provider Services
Это механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки. Также для двухузловых конфигураций и Edge-топологий можно использовать встроенный KMS-сервис, который работает с поддержкой ESXi Key Persistence.
Средства для изолированных окружений
VMware предоставляет Skyline Health Diagnostics tool, который позволяет самостоятельно определить состояние своего окружения в условиях изоляции от интернета. Он сканирует критические компоненты на проблемы и выдает рекомендации по их устранению со ссылками на статьи базы знаний VMware KB.
Улучшения Data In Transit (DIT) Encryption
Здесь появилась валидация FIPS 140-2 криптографического модуля для DIT-шифрования.
Упрощение операций
Улучшения vLCM
Для vSphere Lifecycle Manager появились следующие улучшения:
vLCM поддерживает системы Hitachi Vantara UCP-HC и Hitachi Advanced Servers, а также серверы Dell 14G, HPE10G и Lenovo ThinkAgile.
При создании кластера можно указать образ существующего хоста ESXi.
Улучшения защиты данных
При сбое и недоступности хранилищ хост ESXi, который понял, что произошла авария, начинает записывать дельта-данные с этого момента не только на хранилище, где хранится активная реплика, но и в дополнительное хранилище, чтобы обеспечить надежность данных, создаваемых во время сбоя. Ранее эта технология применялась для запланированных операций обслуживания.
Поддержка Proactive HA
vSAN 7 Update 2 теперь поддерживает технологию Proactive HA, которая позволяет проактивно смигрировать данные машин на другой хост ESXi.
Улучшения мониторинга
Здесь появились новые метрики и хэлсчеки, которые дают больше видимости в инфраструктуре коммутаторов, к которой подключены хосты vSAN. На физическом уровне появились дополнительные метрики, такие как CRC, carrier errors, transmit и receive errors, pauses. Также для новых метрик были добавлены health alarms, которые предупредят администратора о приближении к пороговым значениям.
Улучшения vSphere Quick Boot
Здесь появилась техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.
Скачать VMware vSAN 7 Update 2 в составе vSphere 7 Update 2 можно по этой ссылке. Release Notes доступны тут.
Бонус-видео обзора новых фичей от Дункана Эппинга:
Таги: VMware, vSAN, Update, ESXi, vSphere, Storage, HA, DR, VMachines
Компания VMware выпустила большое обновление серверной платформы виртуализации VMware vSphere 7 Update 2, включающее в себя множество новых возможностей и улучшений. Напомним, что прошлый релиз vSphere 7 Update 1 был выпущен в начале сентября прошлого года, так что времени прошло уже немало.
Нововведения второго пакета обновлений сконцентрированы в трех основных областях:
Давайте посмотрим на новые возможности vSphere 7 Update 2 более детально:
1. Инфраструктура AI и Developer Ready
На основе технологий, анонсированных в 2020 году, компании VMware и NVIDIA сделали совместный анонс платформы AI-Ready Enterprise Platform.
NVIDIA объединилась с VMware для виртуализации рабочих AI-нагрузок в VMware vSphere с помощью NVIDIA AI Enterprise. Это позволяет предприятиям разрабатывать широкий спектр решений для работы с искусственным интеллектом, таких, как расширенная диагностика в здравоохранении, умные предприятия для производства и обнаружение мошенничества в финансовых услугах.
NVIDIA предоставляет пользователям уникальный набор утилит и фреймворков для решения AI-задач на платформе VMware vSphere.
Решение AI Enterprise:
Поддерживает последние поколения GPU от NVIDIA в целях достижения максимальной производительности (до 20 раз лучше, чем в прошлом поколении).
Поддерживает NVIDIA GPUDirect RDMA for vGPUs.
Поддерживает разделение NVIDIA multi-instance GPU (MIG), что позволяет обеспечивать горячую миграцию виртуальных машин c vGPU на борту c помощью vMotion.
Посредством Distributed Resource Scheduler (DRS) обеспечивает автоматическую балансировку машин AI-инфраструктуры по хост-серверам.
Также появились и новые возможности в плане поддержки инфраструктуры контейнеров vSphere with Tanzu:
Интегрированная балансировка нагрузки на приложения посредством VMware NSX Advanced Load Balancer Essentials edition с поддержкой HA с использованием автоматизаций Kubernetes-native (подробнее об этом тут).
Сервисный кластер Tanzu Kubernetes Grid и Supervisor-кластер можно обновить до Kubernetes 1.19.
Улучшенная поддержка сторонних репозиториев, что повышает гибкость и безопасность.
2. Инфраструктурные улучшения и безопасность данных
В этой категории появились следующие новые возможности:
Новый vSphere Native Key Provider - механизм, который позволяет использовать защиту data-at-rest, такую как vSAN Encryption, VM Encryption и vTPM прямо из коробки.
Поддержка Confidential Containers для vSphere Pods, которые используют память AMD SEV-ES и CPU data encryption на платформах AMD EPYC.
Механизм ESXi Configuration Encryption, который использует оборудование Trusted Platform Module (TPM) для защиты ключей ESXi на хостах.
Техника ESXi Key Persistence, которая дает возможности для защиты данных data-at-rest на изолированных хостах.
Обновленные рекомендации vSphere Product Audit Guides, а также FIPS validation для сервисов vCenter Server.
3. Упрощение операций
Техника ESXi Suspend-to-Memory, которая позволяет еще проще обновлять хосты ESXi. Она доступна в комбинации с технологией ESXi Quick Boot. Виртуальные машины просто встают на Suspend в памяти ESXi, вместо эвакуации с хоста, а потом ядро гипервизора перезапускается и хост обновляется.
Оптимизации процессоров AMD EPYC CPU, что приводит к улучшению производительности.
Поддержка рабочих нагрузок Persistent Memory (PMEM) со стороны vSphere HA. Это позволяет техникам DRS initial placement и High Availability полноценно работать в кластере.
Новый функционал решения vSphere Lifecycle Manager with Desired Image Seeding, который позволяет автоматизировать обновление микрокода к желаемому состоянию:
Все фичи vSphere Lifecycle Manager теперь доступны для окружений vSphere with Tanzu.
Функция Desired image seeding позволяет реплицировать информацию о желаемой конфигурации с референсного хоста, экономя время администратора на настройку.
Функция vMotion Auto Scaling, которая позволяет автоматически подстраивать производительность в сетях 25, 40 и 100 Гбит.
Уменьшенное I/O latency и jitter для проброшенных напрямую (passthrough) сетевых адаптеров.
Улучшенная поддержка Virtual Trusted Platform Module (vTPM) для гостевых ОС Windows и популярных дистрибутивов Linux.
Улучшения VMware Tools, включая Guest Store - метод для распространения конфигураций и файлов между виртуальными машинами, а также драйверы Precision Clock drivers для службы Windows Time Service.
Недавно компания Veeam Software, производитель лучших решений для обеспечения доступности виртуального датацентра, выпустила обновление платформы Veeam Cloud Data Management Platform, в состав которой входит самое известное решение для защиты виртуальных сред - Veeam Backup and Replication v11. Мы уже писали об RTM-релизе этого продукта, где вкратце рассказывали его новых возможностях, а сегодня разберем их подробнее.
Итак, собственно основные новые возможности Veeam Backup and Replication v11 (наш топ-15):
1. CDP : Continuous Data Protection
Эта технология позволяет настроить непрерывную защиту виртуальных машин средствами репликации таким образом, чтобы соблюдать заданные политики RPO (Recovery Point Objectives). Достигается это за счет использования технологии VMware VAIO (vSphere API for I/O filtering).
Для этого на хосты ESXi ставится специальный VIB-пакет (фильтр VAIO), который в режиме драйвера привязывается к нужным ВМ.
При создании CDP-политики вы задаете время в секундах, за которое вы можете себе позволить потерять данные в случае сбоя (RPO):
Short-term реплики будут crash-консистентными, а long-term можно уже настроить как Application-aware, чтобы быть уверенным в работоспособности приложений виртуальной машины в конкретной точке в прошлом.
2. Функции асинхронного процессинга
В Veeam v11 при чтении данных с репозиториев происходит их асинхронный процессинг. Это ускоряет процесс для Enterprise-оборудования, но может быть неудобно для недорогих систем хранения, поэтому эту опцию можно отключить в реестре.
3. Возможность Backup Copy Retention
Политика хранения задач Backup copy job теперь имеет такую же логику, как и primary backup job - то есть GFS (Grandfather-Father-Son).
4. Улучшенная работа с тэгами vSphere
Теперь вы можете использовать оператор AND для добавления условия по комбинациям тегов при поиске и создании задач.
5. Представления избранных фильтров
Теперь представление с избранными фильтрами есть в управляющем дереве наравне с самими фильтрами.
6. Защищенный Linux-репозиторий
Возможность создания на Linux-репозиториях бэкапов, которые нельзя удалить (immutability), в целях защиты от вредоносных действий, который может предпринять злоумышленник, заметая следы (также это очень полезно в борьбе с Ransomware, когда может возникнуть ситуация, что вас нет рабочих систем, а бэкапы удалены). Кроме того, это может защитить от намеренной порчи данных изнутри организации.
Очень подробно об этой возможности на русском языке рассказано тут. Эта технология, по аналогии с Instant VM Recovery, позволяет быстро восстановить поврежденную или удаленную базу данных MS SQL из резервной копии. Для этого надо зайти в Restoring Application Items -> Microsoft SQL Server. Далее в Veeam Explorer для нужной базы нужно выбрать опцию Instant Recovery.
Работает сама технология по такой схеме:
8. Возможность восстановления файлов Linux без необходимости развертывания виртуального модуля Helper Appliance
Теперь вам не нужно развертывать эти виртуальные модули, чтобы иметь возможность быстро восстанавливать файлы на Linux. Бэкап можно примонтировать к любой Linux-машине напрямую. Теперь восстановление будет работать быстрее, так как не нужно тратить время на развертывание helper appliance.
Отдельные файлы можно восстанавливать также и в системах IBM AIX, MAC и Oracle Solaris.
9. Улучшенные режимы Linux Backup Proxy
Теперь можно использовать не только методику hot-add, как было в 10-й версии, но и другие режимы (Network Mode, Direct SAN с NFS, iSCSI и FC, а также бэкап из снапшотов хранилищ).
10. Улучшения по программе Veeam Cloud Service Provider
Технология CDP Low second RPO replication, которая позволяет улучшить показатели репликации за счет использования интерфейса vSphere APIs for IO (VAIO).
VCD to VCD Replication – функция для провайдеров VCSP, которая позволяет реплицировать данные между организациями VMware Cloud Director для одного или разных инстансов VCD.
VCD Native HTML5 Plugin - vCloud Director Self Service Portal интегрирован напрямую в VCD.
Улучшенная поддержка объектных хранилищ, в частности появилась поддержка Google Storage.
11. Улучшения Veeam Service Provider Console v5
Новая версия консоли Veeam Service Provider Console v5 даст сервис-провайдерам следующие возможности:
Готовая к производственной эксплуатации третья версия API
Новые возможности контроля над агентами для Windows, Linux и Mac
Возможность управлять бэкапами на AWS и Azure через обновленные нативные плагины
Улучшенные функции безопасности и новые интеграции
12. Модуль PowerShell для Veeam Backup and Replication
Теперь есть интегрированный модуль PowerShell 6.0, который устанавливается по умолчанию. Он позволяет управлять инфраструктурой резервного копирования на базе решений Veeam с помощью сценариев. Также в одиннадцатой версии Veeam B&R появилось 184 новых командлета.
13. Новый Rest API для Veeam Backup and Replication
Теперь Rest API есть не только в Veeam Backup Enterprise Manager, но и непосредственно на бэкап-серверах, что существенно увеличивает гибкость выполнения задач и построения новых интеграций через API.
14. Поддержка Amazon S3 Glacier и Microsoft Azure Archive Storage
Теперь администраторы могут использовать сервисы хранилища Amazon S3 Glacier (включая Glacier Deep Archive) и Microsoft Azure Archive Storage для обеспечения полного цикла облачного хранения резервных копий.
15. Расширение поддержки объектных хранилищ
Теперь можно использовать Google Cloud Storage (GCS) как объектное хранилище за счет нативной интеграции GCS через собственный API Veeam.
Backup & Replication v11 содержит новые версии Veeam ONE v11 (11.0.0.1379), а также апдейт Agent for Windows (5.0.0.4300) и Linux (5.0.0.4318), плюс совершенно новые Mac Agent (1.0.0.713) и Veeam Service Provider Console (5.0.0.6726). Про агенты можно подробно прочитать на русском языке вот тут.
Полный список новых возможностей приведен в документе Veeam v11 What's New (всего их более 200), в котором они занимают аж 21 страницу. Скачать новую версию этого продукта можно по этой ссылке.
Продолжаем рассказывать о лучшем в отрасли решении для создания программных хранилищ под виртуальные машины на базе хост-серверов ESXi - StarWind Virtual SAN for vSphere. Как многие знают, с какого-то момента StarWind стала поставлять свое решение для платформ VMware в виде виртуального модуля (Virtual Appliance) на базе Linux, который реализует основные сервисы хранения, дедупликации и компрессии, а также отказоустойчивости и обеспечения надежности данных в виртуальных машинах.
Для виртуального модуля StarWind работа механизма дедупликации и компрессии обеспечивается средствами Linux-движка Virtual Data Optimizer (VDO), который появился относительно недавно. Это удобный и надежный способ экономии дискового пространства за счет использования дополнительных емкостей оперативной памяти на хосте.
Для начала вам нужно определиться с оборудованием хостов ESXi, где вы будете развертывать виртуальные модули StarWind. Как вы понимаете, в целях обеспечения отказоустойчивости таких узлов должно быть как минимум два.
Что касается HDD и SSD-дисков, то нужно также спланировать конфигурацию RAID на хранилище хостов. Сделать это можно в соответствии с рекомендациями, описанными в базе знаний StarWind. Вы можете использовать программный или аппаратный RAID, о настройках которого мы расскажем ниже.
Что касается дополнительной оперативной памяти на хосте ESXi, то нужно выбирать ее объем, исходя из следующих критериев:
370 МБ плюс дополнительные 268 МБ на каждый 1 ТБ физического хранилища
Дополнительно 250 МБ на 1 ТБ физического хранилища, если включена дедупликация (UDS index)
То есть для 4 ТБ физического хранилища с дедупликацией вам понадобится:
370 MB + 4 * 268 MB +4 * 250 MB = 2 442 MB RAM
Итого 2,4 ГБ оперативной памяти дополнительно к памяти под ОС виртуального модуля. Вообще, StarWind рекомендует 8 ГБ памяти для виртуального модуля - 4 ГБ на машину и 4 ГБ на движок VDO для работы с хранилищем.
Один VDO-том может работать с хранилищем до 256 ТБ, что покрывает максимум потребностей в рамках хранилищ на базе серверов. Также StarWind очень рекомендует использовать дисковые массивы All-flash или NVMe-оборудование.
Общее правило развертывания таких хранилищ таково:
Под VDO: аппаратный или программный RAID (LVM или mdraid)
Над VDO: "толстые" (thick) диски StarWind Virtual SAN в режиме stand-alone или HA
Надо понимать, что сам том VDO - это тонкий диск, растущий по мере наполнения, поэтому устройство под ним должно иметь расширяемую природу (MD RAID, LVM).
Примерная схема отказоустойчивого решения StarWind Virtual SAN for vSphere на базе 2 узлов выглядит так:
После того, как вы установите StarWind Virtual SAN, настроите виртуальную машину и StarWind Management Console, нужно будет настроить аппаратный или программный RAID для хранилища.
Если вы используете аппаратный RAID, то просто создайте виртуальный диск для ВМ StarWind Virtual SAN на его хранилище, но обязательно типа "Thick Provisioned Eager Zeroed" (также вы можете использовать RDM-диск):
Если же вы будете использовать программный RAID, то нужно будет использовать HBA или RAID-контроллер в режиме DirectPath I/O passthrough, чтобы получить прямой доступ к дискам и собрать на их базе RAID-массив.
Для этого вам нужно будте выбрать правильный HBA/RAID-контроллер как PCI-устройство:
И пробросить его напрямую в виртуальную машину StarWind:
После этого в StarWind Management Console можно будет собрать RAID нужного вам уровня:
Рекомендации тут такие:
После этого в виртуальном модуле StarWind на полученном хранилище нужно будет создать VDO-устройство с нужными вам параметрами:
Здесь мы видим, что создается устройство с включенной дедупликацией, выключенной компрессией, нужным размером индексной памяти и заданного объема.
После создания это устройство надо отформатировать в XFS со следующими параметрами:
Далее вы можете создавать хранилище StarWind на этом устройстве и (опционально) сделать его реплику на партнерском узле в режиме HA. Также рекомендуется выставить настройку Disk.DiskMaxIOSize на хосте ESXi
В значение 512:
Ну и про оптимизацию производительности I/O-планировщика прочитайте вот эту статью базы знаний StarWind. Если вам интересен процесс создания хранилищ с дедупликацией и компрессией на базе StarWind Virtual SAN в стиле "от и до", то рекомендуем прочитать вот эту статью.
На днях в различных источниках появились сообщения об уязвимости CVE-2021-21972, которая есть в сервисах vCenter, что может привести к удаленному исполнению кода злоумышленником. Уязвимость по степени критичности оценивается на 9.8 из 10 (по шкале Common Vulnerability Scoring System Version 3.0) и имеет полное описание на сайте VMware как VMSA-2021-0002.
Интересно, что примеры реализации эксплоитов для Windows и Linux на базе этой уязвимости появились как минимум в шести разных местах, включая репозитории на GitHub (например, тут, тут и тут).
VMware сразу же выпустила патч к этой уязвимости, который вы можете загрузить по этой ссылке.
После публикации уязвимости начались массовые сканирования серверов vCenter (кстати, не удивительно, что уязвимость нашел русский инженер, вот ее описание):
Уязвимость использует дырку в плагине vRealize Operations, который установлен по умолчанию, для неавторизованной загрузки файлов по порту 443, после чего становится доступным удаленное исполнение кода в операционной системе vCenter со всеми вытекающими.
В общем, всем нужно поскорее накатывать патч, так как любой с доступом к порту 443 сервера vCenter может потенциально получить к нему полный доступ.
Уязвимость CVE-2021-21972 затрагивает версии vCenter Server 6.5, 6.7 и 7.01. Соответственно, вам нужно накатить 6.5 Update 3n, 6.7 Update 3l или 7.0 Update 1c как можно скорее. Если накатить сейчас не можете, то временный workaround описан в KB 82374.
Недавно компания VMware обновила свое решение Hybrid Cloud Extension (HCX), предназначенное для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud. Версия HCX 4.0 предоставляет возможности большего контроля над процессами миграции, минимизации времени простоя, а также упрощении реконфигурации политик безопасности VMware NSX после миграции.
Давайте посмотрим на новые возможности VMware HCX 4.0:
1. Новая система нумерации релизов и обновленные политики жизненного цикла
Теперь систему версий можно просто представить вот так:
Кроме того, изменились политики жизненного цикла VMware N-2 Lifecycle Policy, которые теперь учитывают новую систему версионирования. Каждый минорный и мажорный релиз HCX будет поддерживаться минимум 12 месяцев со дня выхода.
2. Оценка времени миграции
Теперь решение HCX в реальном времени может оценить время, которое вам понадобится на миграцию нагрузок в виртуальных машинах. Используя механику Mobility Groups, платформа HCX позволяет оценить время миграции каждой конкретной ВМ, составив из этих оценок прогноз по времени миграции группы.
Для первичного развертывания механизм Migration Estimation будет поддерживать только метод миграции Bulk Migration, а в будущем появится поддержка методов vMotion и Replication-Assisted.
3. Информация о событиях миграции
Для всех типов миграции (Bulk, vMotion, Replication-Assisted vMotion и OS-Assisted) предоставляется детальная информация об этих событиях. Там показаны данные всех событий, потоков рабочих процессов, также статусы текущих миграций и многое другое:
Такой уровень детализации очень поможет администраторам при решении проблем, связанных с миграцией рабочих нагрузок в облако. Более подробно об этом вы можете узнать из этого видео.
4. Инфоормация о виртуальных модулях Network Extension
HCX 4.0 предоставляет детальную информацию обо всех расширяемых сетях, реализуемых виртуальными модулями Network Extension (NE). Для них можно увидеть такие параметры, как bit rate, bytes transmitted и received, packet rate, packets transferred и received, с интервалом обновления в 1 минуту. Находится это на вкладке Network Extension Details в разделе Connection Statistics.
5. Перевод виртуальных модулей Network Extension в режим In-Service во время обновления
Виртуальные модули NE могут использоваться не только в процессе миграции, но и после него. Для таких ситуаций теперь есть специальный режим In-Service (как режим обслуживания в vSphere), который позволяет апгрейдить виртуальные модули, сокращая потенциальный простой инфраструктуры и минимизировать прерывания процессов.
6. Миграция тэгов NSX Security Tags
Пользователи VMware NSX Distributed Firewall на источнике миграции могут смигрировать тэги NSX Security Tags в инфраструктуру публичного облака. Это работает для методов миграции Bulk Migration, HCX vMotion, HCX Replication-Assisted vMotion (RAV) и cloud-to-cloud mobility migration. Существующие тэги могут быть на базе решений NSX for vSphere и NSX-T.
Демо процесса миграции тэгов можно посмотреть вот тут.
Ну и в завершение - полезные ссылки, включая ссылку на скачивание VMware HCX 4.0:
Команда PowerCLI компании VMware на днях выпустила обновление средства vSphere Desired State Configuration (DSC) версии 2.2. Механизм DSC есть в экосистеме Windows, начиная еще с Windows Server 2012 R2. С помощью него можно мониторить и управлять конфигурациями систем посредством специальных конфигурационных файлов на базе PowerShell, которые имплементируются через движок Local Configuration Manager (LCM), который должен быть на каждом хосте.
У VMware этот механизм работает несколько иначе, в качестве LCM используется прокси-хост, поскольку LCM не запустить ни на vCenter Server Appliance, ни на ESXi:
Так работал механизм до текущего момента, когда пользователям приходилось разворачивать отдельную Windows-машину под LCM. Но теперь появился модуль VMware.PSDesiredStateConfiguration, который предоставляет пользователям набор командлетов, чтобы скомпилировать и исполнить конфигурацию DCS без использования DSC Local Configuration Manager. Это позволяет использовать как Windows, так и Linux-машину в качестве прокси.
При этом пользователям по-прежнему предоставляется возможность использовать как vSphereDSC с движком PowerShell LCM, так и модуль VMware.PSDesiredStateConfiguration.
Давайте посмотрим, что нового появилось в DCS версии 2.2:
1. Новые ресурсы PowerCLI модуля
Вот они:
DatastoreCluster - создание, изменение, апдейт или удаление Datastore cluster
3. Операция Install/Update для модуля VMware vSphereDSC
Установка модуля теперь делается так:
Install-Module -Name VMware.vSphereDSC
Обновление вот так:
Update-Module -Name VMware.vSphereDSC
4. Новый модуль VMware.PSDesiredStateConfiguration
Как было сказано выше, теперь вы можете использовать Windows или Linux-машину без LCM для использования механизма DCS. Установить модуль можно следующей командой:
Новый командлет New-VmwDscConfiguration создает объект VmwDscConfiguration, который содержит информацию о конфигурации. Эту конфигурацию можно задать в ps1-файле и передать ее данному командлету. Например:
С помощью vSphere Node можно указать объект VINode (сервер vCenter или хост ESXi) и применить соответствующую конфигурацию к нужному узлу vSphere. Это дает следующие возможности:
Персистентные сессии
Раньше для каждого подключения каждый ресурс требовал параметров учетной записи для установки сессии VISession. Теперь же если вы используете Vmware.PSDesiredStateConfiguration то можно создать персистентную VISession, которую можно использовать для всех ресурсов DCS.
Не нужны файлы MOF
Поскольку LCM теперь не используется, то и для командлета New-VmwDSCconfiguration они не требуются. Конфигурация может храниться в переменной, либо в ps1-файле.
Скачать VMware vSphere DSC 2.2 можно по этой ссылке.
Казалось бы, совсем недавно мы писали о выходе Veeam Availability Suite v10, в состав которого входил Veeam Backup & Replication 10, а компания Veeam выпускает уже одиннадцатую версию. Но нет, прошло уже больше года! Поэтому вполне вовремя видеть Veeam Backup & Replication 11, который вступил в стадию RTM-релиза (то есть продукт стал уже доступен для партнеров Veeam).
Пока в блогах Veeam вы можете почитать, что там появилось нового в целом, а после выхода мы расскажем подробности о главных возможностях продукта:
Обратная совместимость и поддержка платформы Veeam
Veeam Backup & Replication, начиная с версии 9.5 Update 4 (build 9.5.4.2866), может сохранять бэкапы через Cloud Connect в облачный репозиторий, включая таковой для версии v11.
Для репликации Cloud Connect Replication, реплики на основе Pre vCloud Director Hardware Plan могут отбрасываться на облачный хост v11.
Backup & Replication v11 содержит новые версии Veeam ONE v11 (11.0.0.1379), а также апдейт Agent for Windows (5.0.0.4300) и Linux (5.0.0.4318), плюс совершенно новые Mac Agent (1.0.0.713) и Veeam Service Provider Console (5.0.0.6726).
Улучшения Veeam Cloud Service Provider
Технология CDP Low second RPO replication, которая позволяет улучшить показатели репликации за счет использования интерфейса vSphere APIs for IO (VAIO).
VCD to VCD Replication – функция для провайдеров VCSP, которая позволяет реплицировать данные между организациями VMware Cloud Director для одного или разных инстансов VCD.
VCD Native HTML5 Plugin - vCloud Director Self Service Portal интегрирован напрямую в VCD.
Улучшенная поддержка объектных хранилищ, в частности появилась поддержка Google Storage.
Текущие лицензии на Veeam Backup & Replication v10 будут действовать и на одиннадцатую версию - получать новые лицензии вам не потребуется.
Улучшения Veeam Service Provider Console v5
Новая версия консоли Veeam Service Provider Console v5 даст сервис-провайдерам следующие возможности:
Готовая к производственной эксплуатации третья версия API
Новые возможности контроля над агентами для Windows, Linux и Mac
Возможность управлять бэкапами на AWS и Azure через обновленные нативные плагины
Улучшенные функции безопасности и новые интеграции
Более подробно о новом релизе Veeam Backup & Replication 11 рассказано на специальной странице вот тут, а в блоге Veeam вы можете найти статьи об отдельных функциях продукта. Официальный запуск новой версии платформы для резервного копирования и репликации состоится через 5 дней.
Компания VMware на днях выпустила обновленную версию инфраструктуры VMware Cloud Foundation (VCF) версии 4.2. Напомним, что это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. О версии платформы VCF 4.1 мы писали вот тут.
Давайте посмотрим, что нового в VCF 4.2:
Поддержка vSAN HCI Mesh Support - теперь VCF поддерживает технологию HCI Mesh в кластерах vSAN, позволяющую использовать емкости удаленных кластеров.
Поддержка NSX-T Federation - теперь можно объединять несколько доменов рабочей нагрузки в одном представлении с помощью Global Manager.
Статические IP-пулы для сетей NSX-T Host Overlay (TEP) - их можно использовать как альтернативу DHCP.
Поддержка режима lockdown mode на хостах ESXi - их можно включать для доменов рабочей нагрузки через vCenter.
Разное: VCF 4.2 включает в себя проверки валидации паролей, оптимизации производительности API, а также улучшения сообщений об ошибках ESXi.
Интерфейс SDDC Manager включает в себя страницу Release Versions с информацией о новых возможностях продукта VCF, составе инфраструктуры и датах окончания поддержки.
В интерфейсе SDDC Manager и через API можно фильтровать бандлы обновлений по целевым релизам, чтобы удобнее было обновляться только на нужные версии.
Поддержка vRealize Automation для облачного аккаунта. Можно интегрировать SDDC Manager и домены рабочей нагрузки с VMware Cloud Assembly как облачными аккаунтами VCF (подробнее тут).
Поддержка сервисных виртуальных машин с использованием образов vSphere Lifecycle Manager (vLCM). Это позволяет развернуть NSX-T Guest Introspection (GI) и NSX-T Service Insertion (SI) в доменах рабочей нагрузки с использованием vLCM.
Обновлен список продуктов и их версий, входящих в инфраструктуру VCF (из главного - vRealize Suite 8.2, NSX-T 3.1 и последние версии vSphere и Horizon).
Полный список возможностей VMware Cloud Foundation 4.2 приведен в Release Notes. Есть также отдельный документ по версии для VxRail.
Гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины в аренду по модели IaaS. Рост числа сотрудников зачастую приводит к необходимости ИТ-масштабирования. Если в компании трудится больше двадцати человек, существовать без адекватной ИТ-инфраструктуры вряд ли получится. Хотя в таком сценарии можно ограничиться малой кровью: распределить функции по ИТ-поддержке между участниками собственной команды...
На днях компания VMware обновила свой главный документ, касающийся обеспечению безопасности виртуальных сред и самой платформы виртуализации - VMware vSphere 7 Security Configuration Guide. Напомним, что о его прошлой версии осенью прошлого года мы писали вот тут.
Давайте посмотрим, что появилось нового в обновленном SCG для vSphere 7, который традиционно состоит из PDF-файла описания и XLS-файла настроек, рекомендаций и пояснений:
Исправлены ошибки в рекомендациях PowerCLI для аудита виртуальных машин.
Добавлена вкладка "Deprecated" - там теперь будут те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).
Настройка svga.vgaOnly перемещена в Deprecated. Она ограничивает ВМ на использование только VGA-разрешений, а многие современные ОС этого очень не любят (могут даже отключить отображение картинки в этом случае).
Добавлены и обновлены рекомендации по отключению сервисных служб SLP и CIM на сервере ESXi. Эти протоколы часто не используются (их не используют и продукты VMware), поэтому лучше их отключить.
Добавлены рекомендации по изоляции сети. Раньше как-то само собой подразумевалось, что нужно разделять сети управления, vMotion и vSAN, теперь же это формализовано в документе. Там же рекомендовано и физическое разделение сетей.
Добавлена рекомендация по использованию только тех продуктов, старые версии которых еще официально поддерживаются со стороны VMware (например, вы можете выполнить все рекомендации и накатить все обновления, но использовать старый ESXi 5, что по понятным причинам небезопасно).
Добавлено руководство по использованию модулей Trusted Platform Modules 2.0 (TPM).
Снова возвращена рекомендация vm-7.pci-passthrough, касающаяся прямого доступа виртуальных машин к оборудованию, в частности шине PCIe.
Добавлено руководство по отключению интерфейсов DCLI, если вы не используете его на vCenter Server. Также вам не нужно держать SSH постоянно открытым, так как в vSphere широкий и защищенный API, который вы можете использовать в разных фреймворках и утилитах.
Скачать VMware vSphere 7 Security Configuration Guide (как и руководства для других версий vSphere) можно по этой ссылке. Подробнее о документе также можно почитать тут.
На сайте VMware Labs появился интересный инструмент Virtualized High Performance Computing Toolkit, который может оказаться полезен компаниям, использующим VMware vSphere для организации высокопроизводительных вычислений (High Performance Computing, HPC). Такие комплексные вычислительные задачи, как правило, вовлекают параллельные вычисления, аппаратное ускорение (такое как GPU и FPGA), а также используют высокоскоростные каналы, такие как RDMA.
Все это требует определенных конфигураций VMware vSphere, для настройки которых и нужно данное средство. С помощью него, используя vSphere API, можно дать администраторам инструменты по сопровождению задач HPC, таких как клонирование ВМ, настройка Latency Sensitivity, сайзинг виртуальных машин по CPU и памяти и многое другое.
Основные возможности тулкита:
Настройка устройств PCIe в режиме DirectPath I/O, таких как GPGPU, FPGA и RDMA
Простое создание и уничтожение кластеров HPC с помощью файлов конфигураций
Выполнение задач vSphere, таких как клонирование, настройка vCPU, памяти, резерваций, shares, Latency Sensitivity, обычного и распределенного виртуального коммутатора, сетевых адаптеров и конфигураций
Например, клонирование 4 виртуальных машин с заданными кастомизациями CPU и памяти, а также добавлением NVIDIA vGPU с профилем grid_p100-4q выглядит так:
Наш постоянный читатель Сергей обратил внимание на то, что на днях компания VMware выпустила обновление своего главного фреймворка для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 12.2. Напомним, что о прошлой версии PowerCLI 12.1 осенью прошлого года мы писали вот тут.
Давайте посмотрим, что нового появилось в обновленном PowerCLI 12.2:
1. Поддержка VMware Horizon
Модуль PowerCLI для управления инфраструктурой Horizon теперь поддерживается для macOS и Linux OS.
2. Инфраструктура VMware Cloud
Появилась поддержка одного из самых популярных сервисов для обеспечения катастрофоустойчивости датацентров - DRaaS. Новые командлеты позволяют включать/отключать DRaaS в виртуальном датацентре VMC SDDC, а также добавлять и удалять инстансы SRM (Site Recovery Manager).
Вот так выглядит включение DRaaS:
Управление инстансами SRM происходит с помощью командлетов:
Иногда администратор VMware vSphere задается вопросом о происхождении виртуальной машины - из какой родительской ВМ/шаблона она была клонирована? Вильям Лам разбирает это в своей статье, приведем вкратце его метод определения происхождения ВМ.
Как вы знаете, бывает три типа клонирования виртуальных машин в VMware vSphere:
Full Clone - это полный клон, то есть независимая копия виртуальной машины, у которой нет ничего связанного с родительской ВМ, это просто ее полная копия.
Linked Clone - это копия виртуальной машины, которая имеет общие диски с родительской, доступные на чтение (это экономит пространство и позволяет просто откатываться к родительскому образу). Уникальные данные эта машина хранит в собственных дельта-дисках.
Instant Clone - это независимая копия виртуальной машины, которая начинает исполняться с какого-то момента и отделяется от основной машины. Для этого используются техники in-memory cloning и copy-on-write, которые используются также и для связанных клонов.
Чтобы найти источник клонированной машины, нужно проанализировать события vCenter Server Events. Вот какие они бывают касательно клонов:
VmClonedEvent - появляется, когда происходит создание Full Clone или Linked Clone.
com.vmware.vc.VmInstantClonedEvent - происходит при созданиии Instant Clone.
VmDeployedEvent - вызывается, когда виртуальная машина развертывается из шаблона (vSphere Template или Content Library Template).
На базе анализа этих трех событий в истории vCenter Вильям Лам создал PowerCLI-функцию Get-VMCloneInfo, с помощью которой можно узнать родителя для виртуальной машины, если она была клонирована.
Устанавливаем ее простой командой:
Install-Script VMCloneInfo
На входе эта функция принимает имя ВМ, которую мы хотим проанализировать. Такой вывод мы получим, если машина не была клонирована:
> Get-VMCloneInfo -VMName "SourceVM"
Unable to find any cloning information for SourceVM, VM may not have been cloned or vCenter Events have rolled over
Так будет выглядеть вывод по полному клону:
> Get-VMCloneInfo -VMName "Full-Clone-VM"
Type Source Date User
---- ------ ---- ----
Full SourceVM 1/3/2021 1:13:00 PM VSPHERE.LOCAL\Administrator
Так мы узнаем, что машина является связанным клоном:
> Get-VMCloneInfo -VMName "Linked-Clone-VM"
Type Source Date User
---- ------ ---- ----
Linked SourceVM 1/3/2021 1:13:14 PM VSPHERE.LOCAL\Administrator
Так - что Instant-клоном:
> Get-VMCloneInfo -VMName "Instant-Clone-VM"
Type Source Date User
---- ------ ---- ----
Instant SourceVM2 1/3/2021 1:12:44 PM VSPHERE.LOCAL\Administrator
Вот пример того, что машина была клонирована из шаблона vSphere Template:
> Get-VMCloneInfo -VMName "VMTX-VM"
Type Source Date User
---- ------ ---- ----
Full SourceVMTXTemplate 1/3/2021 2:20:31 PM VSPHERE.LOCAL\Administrator
А вот - что из шаблона Content Library VM Template:
> Get-VMCloneInfo -VMName "VMTemplate-VM"
Type Source Date User
---- ------ ---- ----
Full SourceVMTemplate 1/3/2021 2:23:41 PM VSPHERE.LOCAL\Administrator
На сайте virten.net, как обычно, вышла замечательная статья о реальной боли некоторых администраторов VMware vSphere - уменьшении дисков vCenter Server Appliance (vCSA). Так как vCSA работает в виртуальной машине, то иногда возникает необходимость в уменьшении ее дисков в целях простоты перемещения и компактности хранения. Но основная ситуация, когда диски vCSA чрезмерно разрастаются - это апгрейд сервера vCenter - в этом случае его хранилище может увеличиться до 1 ТБ при реально занятом пространстве в 100 ГБ. Тут уже без шринка (shrink) не обойтись.
При апгрейде vCSA установщик смотрит на аллоцированное пространство, а не на занятое, поэтому исходная машина в 416 ГБ может быть преобразована только в целевую ВМ типа Small с 480 ГБ диска:
Метод, описанный ниже, стоит применять только для виртуального модуля vCSA, который вы планируете апгрейдить, поскольку меняется порядок его дисков. Это, в целом, не проблема, но могут возникнуть сложности при взаимодействии с поддержкой VMware, которая может посчитать эту конфигурацию неприемлемой.
Перво-наперво нужно сделать бэкап вашего vCSA или его клон, с которым вы и будете работать. Если что-то не получится, вы просто сможете удалить клон.
Итак, заходим на vCSA по SSH и останавливаем все службы:
# service-control --stop --all
Выбираем файловую систему, для которой будем делать shrink. Например, /storage/seat имеет размер 296 ГБ, но реально используется 67 МБ! Запоминаем файловую систему (/dev/mapper/seat_vg-seat) и точку монтирования хранилища (/storage/seat), которое будем уменьшать.
Также из файловой системы вы можете получить Volume Group (seat_vg) и Logical Volume (seat):
Когда миграция будет закончена, sdh должен остаться пустым (Allocated PE = 0 и нет физических сегментов, только FREE):
# pvdisplay -m /dev/sdh
--- Physical volume ---
PV Name /dev/sdh
VG Name seat_vg
PV Size 300.00 GiB / not usable 7.00 MiB
Allocatable yes
PE Size 8.00 MiB
Total PE 38399
Free PE 38399
Allocated PE 0
PV UUID V7lkDg-Fxyr-qX4x-d3oi-KhNO-XZyT-EHgibI
--- Physical Segments ---
Physical extent 0 to 38398:
FREE
Удаляем sdh из Volume Group:
# vgreduce seat_vg /dev/sdh
Удаляем LVM-метки из sdh:
# pvremove /dev/sdh
Запускаем скрипт autogrow.sh для расширения файловой системы к размеру виртуального диска:
/usr/lib/applmgmt/support/scripts/autogrow.sh
Последний шаг очень важен - удаляем старый диск. Не удалите не тот! Для этого проверяем SCSI ID с помощью lsscsi:
# lsscsi |grep sdh
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
Мы видим, что SCSI ID [2:0:8:0] нам нужно удалить. Помните, что номер диска не всегда совпадает с SCSI ID. Удалите правильный диск (в данном случае 8), не ошибитесь!
Это все, теперь можно перезагрузить виртуальную машину, после чего в качестве опции апгрейда будет доступен вариант апгрейда на Tiny:
Если вы хотите уменьшить другие разделы, то идентифицируйте соответствующие параметры Logical Volume, Volume Group и Virtual Disk, после чего повторите процедуру.
# lsscsi
[0:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0
[2:0:0:0] disk VMware Virtual disk 1.0 /dev/sda
[2:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb
[2:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc
[2:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd
[2:0:4:0] disk VMware Virtual disk 1.0 /dev/sde
[2:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf
[2:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh
[2:0:9:0] disk VMware Virtual disk 1.0 /dev/sdi
[2:0:10:0] disk VMware Virtual disk 1.0 /dev/sdj
[2:0:11:0] disk VMware Virtual disk 1.0 /dev/sdk
[2:0:12:0] disk VMware Virtual disk 1.0 /dev/sdl
[2:0:13:0] disk VMware Virtual disk 1.0 /dev/sdm
На днях компания VMware выпустила обновление виртуального модуля Horizon Cloud Connector 1.9, который позволяет соединить ваш Horizon Connection Server с облачным средством управления VMware Horizon Control Plane для создания гибридной среды виртуализации и доставки настольных ПК и приложений. О том, что нового было в прошлом релизе, можно почитать вот тут.
1. Улучшения интерфейса конфигурации сети
Раньше для настройки возможности автоматического обновления администраторам приходилось указывать все параметры сети (DNS, gateway, маску и IP). Теперь же нужно указать статический IP, который будет временно использован для обновления виртуального модуля. Все остальные параметры подтянутся автоматически из конфигурации Virtual Appliance.
2. Улучшения SSH
Доступ по SSH теперь отключен для пользователей root. Теперь для доступа по SSH есть специальный пользователь "ccadmin". Ему уже можно дать возможность повышения привилегий после логина. Поддерживается аутентификация как по ключу, так и по паре логин-пароль, но лучше использовать первый способ.
Ну и, пользуясь случаем, приведем ссылки на полезные статьи серии "Horizon Cloud Connector Know-How Series":
Компания VMware выпустила обновление средства vRealize Network Insight 6.1. Напомним, что оно предназначено для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений. О прошлой версии vRNI 6.0 мы писали вот тут.
Давайте посмотрим, что нового в vRNI 6.1:
Функции Network Assurance and Verification
Для определения несоответствия native VLAN и native VLAN tagging были добавлены цели (Intents)
Поддержка сетевого экрана Supports Palo Alto Networks (PAN) Firewall в представлении Network Map
Поддержка устройств Juniper в Network Map через утилиту Netconf (SSH не требуется)
Улучшения юзабилити (поиск путей, включая данные о конфигурации)
Аналитика на базе целей (Intent based analytics) - поддержка Link Metering для VMware SD-WAN
Создание цели для отслеживания использования канала (bandwidth) на соединениях (LTE/MPLS), которые находятся на обслуживании у сервис-провайдеров
Проактивные алерты помогают избежать дополнительных затрат за использование канала при превышении лимита провайдера
Поддержка возможности оптимизации или экономии полосы канала по этим соединениям
Intent based analytics для мониторинга использования Edge Uplink
Возможность создания целей для мониторинга использования аплинков на VMware SD-WAN Edges, для того чтобы оптимизировать использования канала, отслеживать проблемы и планировать увеличение емкостей каналов
Поддержка возможности выбора типа аплинка для генерации алертов и нотификаций
Сервисная информация Layer 7 от движка NSX Intelligence
Возможность получить видимость на уровне 7, когда включен движок NSX Intelligence через NSX-T Manager
Улучшенные дэшборды, включая VM, Hosts и Application - там теперь есть информация на уровне 7 OSI
Мониторинг и траблшутинг NSX-T
Алерты можно фильтровать на базе сущностей и конфигураций
Графики метрик для визуализации взаимодействия
Метрики для объектов NSX-T теперь показываются на странице NSX-T Manager Topology
Для маскирования правил сетевого экрана были добавлены события
Метрика Flow retransmit count поменялась на flow retransmit percentage
Функции VMware Cloud on AWS (VMC on AWS)
Поддержка статистик VMC T0 Router Interface, включая Rx Total Bytes, Rx Total Packets, Rx Dropped Packets, Tx Total Bytes, Tx Total Packets и Tx Dropped Packets для соединений Public, Cross-VPC и Direct Connect
Мониторинг и траблшутинг физических устройств
Графики метрик для визуализации взаимодействия
Функции поиска
Альтернативные предложения запросов, когда ничего не найдено
Pinboard
При прикреплении нового фильтра состояние фильтра сохраняется
Возможность прикреплять пустые результаты поиска (могут стать непустыми потом)
Возможность видеть другие пинборды под пользователем с ролью Auditor
Алерты
Определения алертов (раньше это были события) теперь классифицированы по категориям и по-разному организованы в интерфейсе для упрощения управления ими
Определение алерта используется для отсылки к проблеме или изменения условия срабатывания
Улучшения платформы
Поддержка веб-прокси для data sources (SD-WAN, AWS, Azure, ServiceNow, VMC NSX Manager)
Показ информации о машинах Platform и Collector на одной странице (IP, активность, статус и т.п.)
Возможность добавления и обновления data sources
Страница информации обо всех Web Proxies, а также использования ими ресурсов
Страница Infrastructure and Support
Прочие улучшения
VMware vRealize Network Insight Cloud доступен в Австралии
vRealize Suite Lifecycle Manager 8.2 Product Support Pack 1 поддерживает установку vRealize Network Insight 6.1
Скачать VMware vRealize Network Insight 6.1 можно по этой ссылке. Release Notes доступны тут.
Многие администраторы VMware vSAN задаются вопросом - а сколько прослужат диски в кластере хранилищ? Сегодня для vSAN уже имеет смысл использовать только SSD-диски, так как их стоимость уже вполне стала приемлемой для построения All-Flash хранилищ.
Как известно, в кластере vSAN есть 2 типа дисков - Cache (кэширование данных перед записью на постоянное хранение) и Capacity (постоянное хранилище). В первом случае, конечно же, использование ресурса диска идет в разы быстрее, чем для Capacity Tier.
Florian Grehl в своем блоге провел замер использования дисков обоих ярусов в плане записанных гигабайт в сутки в тестовой лаборатории. Вы сами сможете сделать это с помощью его PowerCLI-сценария, а также визуализовав данные в Graphite.
У него получилась вот такая картина:
В день у него получилось:
300 ГБ на диски Caching tier
20 ГБ на диски Capacity tier
Надо понимать, что объем записанных данных на каждый диск зависит от числа дисков в группе, а также развернутого типа RAID и политики FTT.
Когда вы покупаете SSD-диск, гарантия на него идет как на машину: время (обычно 5 лет), либо пробег (а в случае с диском это "TBW" = Terabytes Written, то есть записанный объем в ТБ) - в зависимости от того, что наступит раньше.
Как правило, для Capacity tier ресурс TBW за 5 лет на практике выработать не получится, а вот для Caching tier неплохо бы этот параметр замерить и сопоставить с характеристиками дисков. Например, 300 ГБ в день дает 535 ТБ за 5 лет.
Ну а вот параметры TBW, например, для устройств Samsung:
Вендор
Диск
Емкость
TBW
Гарантия
Samsung
980 PRO NVMe M.2 SSD
250
150
5 лет
Samsung
980 PRO NVMe M.2 SSD
500
300
5 лет
Samsung
980 PRO NVMe M.2 SSD
1000
600
5 лет
Samsung
950 PRO NVMe M.2 SSD
256
200
5 лет
Samsung
950 PRO NVMe M.2 SSD
512
400
5 лет
Samsung
SSD 870 QVO SATA III 2.5 Inch
1000
360
3 года
Samsung
SSD 870 QVO SATA III 2.5 Inch
2000
720
3 года
Samsung
SSD 870 QVO SATA III 2.5 Inch
4000
1440
3 года
Samsung
SSD 870 QVO SATA III 2.5 Inch
8000
2880
3 года
Samsung
970 EVO Plus NVMe M.2 SSD
250
150
5 лет
Samsung
970 EVO Plus NVMe M.2 SSD
500
300
5 лет
Samsung
970 EVO Plus NVMe M.2 SSD
1000
600
5 лет
Samsung
970 EVO Plus NVMe M.2 SSD
2000
1200
5 лет
Samsung
860 QVO SATA III 2.5 Inch SSD
1000
360
3 года
Samsung
860 QVO SATA III 2.5 Inch SSD
2000
720
3 года
Samsung
860 QVO SATA III 2.5 Inch SSD
4000
1440
3 года
Samsung
970 EVO NVMe M.2 SSD
250
150
5 лет
Samsung
970 EVO NVMe M.2 SSD
500
300
5 лет
Samsung
970 EVO NVMe M.2 SSD
1000
600
5 лет
Samsung
970 EVO NVMe M.2 SSD
2000
1200
5 лет
Samsung
970 PRO NVMe M.2 SSD
512
600
5 лет
Samsung
970 PRO NVMe M.2 SSD
1000
1200
5 лет
Samsung
860 EVO SATA III 2.5 Inch SSD
250
150
5 лет
Samsung
860 EVO SATA III 2.5 Inch SSD
500
300
5 лет
Samsung
860 EVO SATA III 2.5 Inch SSD
1000
600
5 лет
Samsung
860 EVO SATA III 2.5 Inch SSD
2000
1200
5 лет
Samsung
860 EVO SATA III 2.5 Inch SSD
4000
2400
5 лет
Samsung
SSD 860 PRO SATA III 2.5 Inch
256
300
5 лет
Samsung
SSD 860 PRO SATA III 2.5 Inch
512
600
5 лет
Samsung
SSD 860 PRO SATA III 2.5 Inch
1000
1200
5 лет
Samsung
SSD 860 PRO SATA III 2.5 Inch
2000
2400
5 лет
Samsung
SSD 860 PRO SATA III 2.5 Inch
4000
4800
5 лет
Samsung
860 EVO SATA III M.2 SSD
250
150
5 лет
Samsung
860 EVO SATA III M.2 SSD
500
300
5 лет
Samsung
860 EVO SATA III M.2 SSD
1000
600
5 лет
Samsung
860 EVO SATA III M.2 SSD
2000
1200
5 лет
Intel
Intel Optane Memory 16GB
16
182.5
5 лет
Intel
Intel Optane Memory M10 16GB
16
365
5 лет
Intel
Intel Optane Memory 32GB
32
182.5
5 лет
Intel
Intel Optane Memory M10 32GB
32
365
5 лет
Intel
Intel Optane SSD 800P 58GB
58
365
5 лет
Intel
Intel Optane SSD 800P 58GB
118
365
5 лет
Intel
Intel® 545s-SSDs
256
144
5 лет
Intel
Intel® 545s-SSDs
512
288
5 лет
Intel
Intel® 545s-SSDs
256
144
5 лет
Intel
Intel® 660p-SSDs
512
100
5 лет
Intel
Intel® 660p-SSDs
1024
200
5 лет
Intel
Intel® 660p-SSDs
2048
400
5 лет
Intel
Intel® 760p-SSDs
128
72
5 лет
Intel
Intel® 760p-SSDs
256
144
5 лет
Intel
Intel® 760p-SSDs
512
288
5 лет
Intel
Intel® 760p-SSDs
1024
576
5 лет
Intel
Intel® 760p-SSDs
2048
576
5 лет
Transcend
PCIe SSD 220S
256
550
5 лет
Transcend
PCIe SSD 220S
512
1100
5 лет
Transcend
PCIe SSD 220S
1000
2200
5 лет
Transcend
PCIe SSD 220S
2000
4400
5 лет
Seagate
IronWolf 510
240
435
5 лет
Seagate
IronWolf 510
480
875
5 лет
Seagate
IronWolf 510
960
1750
5 лет
Seagate
IronWolf 510
1920
3500
5 лет
Как видно из таблицы, некоторые устройства могут прослужить вам значительно меньше 5 лет, в зависимости от интенсивности использования в вашей инфраструктуре и модели устройства.
Некоторое время назад мы писали об улучшении технологии горячей миграции vMotion (тут и тут) в последней версии VMware vSphere 7 Update 1. Сегодня мы вкратце расскажем о вариантах переноса рабочих нагрузок в кластер хранилищ VMware vSAN на базе вот этой заметки.
Первое, что вы должны решить - это в каком рабочем процессе вы будете мигрировать виртуальные машины с помощью vMotion: за один шаг (хранилище+сервер) или за два (сначала сервер, потом хранилище).
1. Миграция в два шага (Two-Step Migrations)
При выборе миграции виртуальной машины у нас есть опция изменения либо сервера ESXi машины, либо ее хранилища, либо и того, и другого:
Change compute resource only - это первый шаг миграции для случая, когда не-vSAN хранилище может быть презентовано существующему кластеру vSAN. Также это может быть востребовано в рамках топологии VMware vSAN HCI Mesh, где хранилище монтируется удаленному кластеру vSAN.
Change storage only - это второй шаг миграции, когда машина на хосте ESXi уже находится в кластере vSAN, и мы выполняем перенос ее VMDK уже на собственные хранилища кластера.
Надо сказать, что миграция машин в два шага имеет бОльшую гранулярность, что позволит вам получить промежуточный результат и зафиксировать результат в середине (например, смигрированная на другой хост, но не хранилище машина), что может сэкономить время при повторной попытке миграции в случае каких-то проблем.
2. Миграция в один шаг
Этот способ миграции реализуется, когда вы выбираете опцию Change both compute resource and storage или Cross vCenter Server export. Надо понимать, что процесс этот весьма затратный, и выбирать этот вариант можно, когда у вас есть большой запас по ресурсам и времени для вычислительных ресурсов и ресурсов хранилищ. Ну или когда вы не можете расшарить хранилище между двумя разными кластерами vSphere / vSAN.
Удобство это способа еще и в том, что если у вас есть много времени на миграцию, то можно просто поставить vMotion для нужных нагрузок, и все будет постепенно переезжать без участия администратора.
Также для переноса нагрузок между разными инфраструктурами есть опция Cross vCenter Server export. В обновлении VMware vSphere 7 Update 1c главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.
Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.
Если вы решили сделать пакетную миграцию виртуальных машин в vSphere Client, то нужно для кластера или пула ресурсов перейти на вкладку VMs и с шифтом выбрать группу ВМ для миграции, после чего из контекстного меню выбрать Migrate...:
Надо сказать, что машины одной группы можно мигрировать только в одинаковом состоянии (Powered on или Powered off), поэтому удобно отсортировать их по колонке State.
Ну и в заключение - картинка об улучшении технологии vMotion с момента ее появления в 2003 году:
На сайте проекта VMware Labs обновились четыре полезные утилиты, про которые мы уже не раз писали. Давайте посмотрим, что именно в них появилось нового:
1. VMware OS Optimization Tool билд b2001
Про прошлый апдейт этой утилиты мы писали вот тут. Напомним, что это средство предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.
Что появилось нового:
Все записи оптимизаций снова добавили в шаблон main user template, теперь можно их тюнинговать вручную.
Исправлены два параметра аппаратных оптимизаций и ускорения, которые ранее настраивались в одной опции.
Во время фазы Optimize оптимизации экспортируются в файл json (%ProgramData%\VMware\OSOT\OptimizedTemplateData.json).
Во время фазы Analyze, если дефолтный файл json существует (то есть образ уже оптимизирован), то он импортируется и используется при выборе оптимизаций с прошлым выбором параметров. Также если выбор дефолтных состояний обязателен, то перед каждым запуском утилиты нужно удалять этот файл.
Файл OptimizedTemplateData.json можно использовать в командной строке с параметром -applyoptimization.
Улучшена работа с параметрами для служб Hyper-V, которые требуются для облачного сервиса Azure.
Скачать VMware OS Optimization Tool можно по этой ссылке.
2. vSphere Software Asset Management Tool версии 1.3
Напомним, что Software Asset Management Tool предназначен для сбора подробной информации об инсталляции VMware vSphere на вашей площадке, касающуюся лицензирования - инвентаря и доступности лицензий.
О прошлой версии этой утилиты мы писали вот тут, а вот что появилось нового в версии 1.3:
Отображение продуктов семейства Tanzu в генерируемых отчетах
Несколько исправлений ошибок
Скачать Software Asset Management Tool 1.3 можно по этой ссылке.
3. DRS Dump Insight версии 2.0
Напомним, что о прошлой версии Dump Insight 1.1 мы писали здесь. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS.
Давайте посмотрим, что появилось нового:
Добавлена поддержка дампов vSphere 7.0 и 7.0 Update 1
Доступен выбор нескольких отдельных дампов для анализа из общего списка
Об этой утилите мы писали вот тут. Она позволяет показывать различную информацию об оконечных устройствах на рабочих станциях (Certificate Management, Application Deployment, Profile Management).
Что появилось нового:
Обновлена иконка приложения
Появился мониторинг компонентов VMware Horizon Client, VMware Digital Experience Telemetry и VMware Hub Health services
Скачать Workspace ONE Discovery 1.1 можно по этой ссылке.
Компания VMware обновила свое руководство для быстрого старта с инфраструктурой виртуализации настольных ПК и приложений - Quick-Start Tutorial for VMware Horizon 8. Это один из самых популярных материалов на VMware TechZone на сегодняшний день, он позволяет начинающим администраторам VMware vSphere и Horizon развернуть тестовую VDI-среду в своей компании за пару часов.
VMware проделала значительную работу по оптимизации руководства, и теперь его объем сокращен с 222 страниц (для Horizon 7) до 63 страниц (Horizon 8). Все это позволяет быстро начать развертывание решения, а уже потом постигать детали.
То, что вы будете делать, в рамках прочтения руководства и развертывания продукта, будет выглядеть так:
Основные фазы будут следующего содержания:
Install - начнете с установки Horizon Connection Server, который управляет сессиями пользователей для десктопов и приложений на базе веб-консоли Horizon Administrative Console.
Prep - с использованием vSphere Client вы создадите образы Windows-десктопов, а также сервера RDSH для виртуализованных приложений. Кроме того, вы поставите Horizon Agent в гостевые ОС.
Configure - создадите пул виртуальных ПК и ферму серверов с виртуализованными приложениями, а также назначите для них права доступа.
Output - из iOS, Android, Chromebook, Windows, macOS или Linux подключитесь к виртуальным ПК, загрузив соответствующую версию Horizon Client или зайдя через браузер (HTML Access web client).
После выполнения всех описанных задач вы получите готовую инфраструктуру Horizon с несколькими опубликованными приложениями (на базе сервисов Microsoft Remote Desktop Session Host, RDSH), а также пул виртуальных десктопов на базе Windows 10.
Руководство Quick-Start Tutorial for VMware Horizon 8 доступно по этой ссылке.
Решение для виртуализации сетей VMware NSX-T, в отличие от его vSphere-версии NSX-V, не имеет графического интерфейса для настройки отсылки логов на серверы Syslog.
Graham Smith написал краткую заметку о настройке Syslog для решения VMware NSX-T, включая NSX-T Manager, узлы Edge Nodes и серверы ESXi.
Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware Log Insight. Сначала заходим по SSH на NSX-T Manager и выполняем там следующую команду, указав IP-адрес сервера Log Insight:
MulNSXT01> set logging-server 192.168.10.8 proto udp level info
WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.
На узлах Edge Nodes
также нужно выполнить такую же команду, зайдя по SSH:
DCA-MulNSXT-ESG01> set logging-server 192.168.10.8 proto udp level info
WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.
На серверах ESXi процесс выглядит несколько иначе. Нужно выполнить вот такую последовательность команд:
[root@DCA-MulComp01:~] esxcli network firewall ruleset set -r syslog -e true
[root@DCA-MulComp01:~] esxcli system syslog config set --loghost=udp://192.168.10.8:514
[root@DCA-MulComp01:~] esxcli system syslog reload
[root@DCA-MulComp01:~] esxcli system syslog mark -s "This is a test message"
Первая команда разрешает в фаерволе трафик Syslog, вторая - настраивает сервер адрес сервера, третья - подхватывает настройки, ну а четвертая - отсылает тестовое сообщение, чтобы можно было проверить работоспособность механизма Syslog со стороны Log Insight.
Там это тестовое сообщение можно увидеть в разделе Events:
Чтобы проверить логирование на стороне фаервола, можно создать простое правило с тестовым тэгом:
Далее в Log Insight можно увидеть это событие, поискав по этому тегу:
Чтобы проверить конфигурацию Syslog на стороне сервера ESXi, нужно выполнить следующую команду:
[root@DCA-MulComp01:~] esxcli system syslog config get
Check Certificate Revocation: false
Default Network Retry Timeout: 180
Dropped Log File Rotation Size: 100
Dropped Log File Rotations: 10
Enforce SSLCertificates: true
Local Log Output: /scratch/log
Local Log Output Is Configured: false
Local Log Output Is Persistent: true
Local Logging Default Rotation Size: 1024
Local Logging Default Rotations: 8
Log To Unique Subdirectory: false
Message Queue Drop Mark: 90
Remote Host: udp://192.168.10.8:514
Strict X509Compliance: false
На стороне NSX-T Manager и на узлах Edge Nodes конфигурацию Syslog можно проверить такой командой:
DCA-MulNSXT-ESG01> get logging-servers
Mon Dec 28 2020 UTC 17:37:16.600
192.168.10.8:514 proto udp level info
Большинство администраторов, которым требуется управление виртуальной инфраструктурой VMware vSphere с помощью сценариев используют интерфейс VMware PowerCLI, который является оберткой движка PowerShell. Это требует наличие отдельного хоста, с которого идет исполнение сценариев, а также часто требуются такие сервисы, как vRealize Orchestrator и vRealize Automation.
Поэтому, начиная с VMware vSphere 6.7, появился новый Open Source интерфейс для управления виртуальной средой - Script Runtime Service (SRS). Он представляет собой Kubernetes-приложение для управления инстансами PowerCLI и вызова командлетов через REST API.
Интерфейс SRS позволит интегрировать управление исполнением сценариев PowerCLI в vSphere Client для виртуальных машин и приложений.
SRS создает отдельное пространство имен в кластере Kubernetes, которое позволяет PowerCLI работать как Kubernetes pod. Этот легковесный PowerCLI pod реализуется как образ контейнера, который имеет все модули PowerCLI и требует только необходимые управляющие компоненты, трансформирующие ввод и вывод для сценариев, а также управляющие исполнением запрошенного сценария.
Первоначальная инсталляция SRS запускает задачу Kubernetes, которая регистрирует SRS в сервисах провайдера идентификации vSphere SSO. Единожды аутентифицированные клиенты SRS API автоматически включаются в список доверенных на серверах vCenter.
Надо отметить, что сейчас SRS находится еще в ранней стадии разработки и не работает с vSphere with Tanzu (поэтому не развертывайте его со службами Supervisor Cluster).
Попробовать работу с движком SRS можно двумя путями:
1. Устанавливаете SRS в кластере Kubernetes на любую из машин (инструкции здесь)
2. Устанавливаете SRS на специальным образом подготовленную виртуальную машину на базе Photon OS (инструкции тут).
Начать экспериментировать с SRS API можно, перейдя по ссылке:
https://{SRS-IP}/swagger/index.html
SRS использует механизм vCenter Server SSO для идентификации и аутентификации. У любого пользователя с доступом через SSO есть возможность настроить PowerCLI-соединения к серверам vCenter Servers. Как начать это делать описано вот тут.
SRS работает с vSphere 6.7 и более поздними версиями. Сообщить о проблемах вы можете вот тут, а также присодинившись к VMware Code и каналу в Slack.
На днях компания VMware выпустила обновление своего пакета vRealize Operations Management Pack for Kubernetes 1.5.1, которое позволяет отслеживать состояние контейнерных сред Kubernetes из консоли Operations. Напомним, что ранее оно называлось Management Pack for Container Monitoring.
Надо отметить, что vRealize Operations с помощью данного пакета может обеспечивать мониторинг как сред Tanzu Kubernetes в публичном или онпремизном облаке, так и инфраструктуры OpenStack с развернутыми кластерами Kubernetes.
Давайте посмотрим, что появилось нового в MP for Kubernetes 1.5.1:
1. Поддержка vRealize Operations Advanced
Теперь пользователи издания Advanced также могут использовать пакет управления, ранее эта возможность была доступна только владельцам лицензий Enterprise. Для vRealize Operations Cloud поддержка также сохранилась.
2. Улучшенный сбор метрик средствами Prometheus
Многие пользователи сред Kubernetes используют Prometheus для сбора метрик в кластерах. Теперь vRealize Operations за счет MP может запрашивать метрики с сервера Prometheus, а данные об инфраструктуре получать напрямую через Kubelet API.
Такая интеграция по-прежнему позволит вам использовать механизмы интеллектуального анализа данных, в том числе Troubleshooting Workbench и Metric Correlation.
Prometheus хранит данные в отличном от vRealize Operations формате. Чтобы преобразовать и получить данные для метрик Prometheus можно использовать следующих экспортеров (exporters):
Если ваша команда разработки дорабатывает какие-то метрики в экспортерах, то они автоматически становятся доступны в vRealize Operations.
vRealize Operations также собирает метки (labels) с серверов Prometheus. Они могут включать важные данные, такие как IP-адреса узлов, имена приложений или процессов, номера версий или даже, например, какие метрики используются для конкретного ядра CPU:
Для игнорирования ненужных метрик (например, GUID) можно использовать фильтры:
3. Мониторинг приложений в Kubernetes
Теперь интеграция vRealize Operations и Prometheus позволяет более глубоко взглянуть на уровень приложений:
В данном примере показано приложение Redis, для которого используется экспортер Telegraf. Для него vRealize Operations может видеть такие метрики как: число клиентов, как много времени CPU требуется на выполнение вызовов, информацию о памяти и application backlogs.
4. Поддержка новых Tanzu Mission Control API
Теперь vRealize Operations и MP могут не только автоматически мониторить облачные среды Tanzu Mission Control на платформе AWS, но и полностью поддерживают обновленный API. Также недавно было анонсировано, что Tanzu Mission Control будет поддерживать Tanzu Kubernetes Grid on vSphere 7, и вскоре эта поддержка будет добавлена и в Management Pack.
Скачать VMware vRealize Operations Management Pack for Kubernetes 1.5.1 можно по этой ссылке. Документация находится здесь.
Компания Veeam, производитель лидирующих на рынке средств для обеспечения доступности виртуальных датацентров, в декабре объявила о доступности для скачивания новой версии Veeam Backup for Microsoft Office 365 v5. Напомним, что с помощью этого решения можно производить резервное копирование и восстановление данных Office 365 из облака, а также бэкапить локальные данные Microsoft Exchange, OneDrive и Sharepoint.
Давайте посмотрим, что нового появилось в этом решении:
1. Поддержка Microsoft Teams
Многие Enterprise-администраторы используют Microsoft Teams для создания среды совместной работы для команд различного размера в рамках предприятия. Теперь Veeam Backup for Microsoft Office 365 v5 позволяет производить резервное копирование этих сред с использованием специального API от Microsoft.
Этот API позволяет узнать, с каким каналом ассоциирован каждый data point, что позволяет организовать бесшовное резервное копирование и восстановление сред Microsoft Teams для SharePoint Online, Exchange и OneDrive.
Veeam Explorer for Microsoft Teams включает в себя возможности восстановления для каналов, настроек, прав доступа, приложений и вкладок, включая данные и компоненты.
Также появилась возможность поиска по 17 полям:
2. Улучшения производительности
Теперь объекты SharePoint обрабатываются параллельно для каждого сайта, что существенно ускоряет процесс бэкапа. Также одна инсталляция бэкап-сервера может обрабатывать до 5 раз больше прокси, что увеличивает возможности по управлению бэкапом больших инфраструктур. При этом прокси не обязательно должны быть в том же или трастовом домене.
Кроме того, теперь данные Office 365 в два раза быстрее перемещаются между локальной БД и объектным хранилищем репозиториев.
3. Обновление Restful API
Помимо поддержки Microsoft Teams, появились функции отчетности о ежемесячном использовании ресурсов, что позволяет гибко использовать эту информацию в целях биллинга (она поставляется в виде JSON). Через API теперь также можно управлять лицензиями пользователей.
Скачать можно по этой ссылке. Также Veeam выпустила целую книжку "Microsoft Teams Backup", в которой описаны лучшие практики по резервному копированию таких пользовательских сред.
Вот список продуктов и их версий, которые затронет отсутствие поддержки Flash со стороны браузеров:
Продукт
На что нужно обновляться
vSphere 6.7 GA или старее
6.7 Update 3 или новее
Horizon 7.8 или старее
7.10 или новее
vCloud Director 10 или старее
10.1 или новее
NSX for vSphere 6.4.7 или старее
6.4.8 или новее
Site Recovery Manager 6.5 или старее
8.1 или новее
vSAN 6.5 или старее
6.7 Update 3 или новее
vRealize Orchestrator 7.5 или старее
7.6 или новее
vRealize Automation 7.6 или старее
8.0 или новее
vRealize Operations 6.5 или старее
6.6 или новее
В июне этого года, в связи с большим числом заявок от крупных компаний, было решено сделать Workaround для Flash Player. Чтобы включить его для отдельных URL, нужно внести изменения в файл mms.cfg, где следует добавить следующие строчки:
Это гостевой пост нашего партнера, сервис-провайдера ИТ-ГРАД, предоставляющего услуги аренды виртуальных машин из облака. Уже в начале шестидесятых портфолио IBM насчитывало десятки различных систем. Каждое новое поколение разительно отличалось от предыдущего. Покупатели рвали на себе волосы в тщетных попытках поспеть за всеми инновациями и требованиями нового железа...
В прошлом году мы писали о полезной утилите VMware Configuration Maximums Tool, которая позволяет выводить максимальные конфигурации для различных продуктов VMware. Эта очень полезная штука для администраторов vSphere умеет не только выводить список всех максимумов, но и сравнивать их для разных версий одного продукта.
Для этого нужно выбрать пункт меню "Compare Limits" и указать сравниваемые версии продуктов:
Штука эта очень удобная, но у нее есть большой недостаток - она выводит все конфигурации максимумов (для NSX-T, например, их 274 штуки, поэтому сложно отследить, что именно изменилось).
Поэтому Dale Coghlan написал интересный PowerCLI-модуль VMware.CfgMax, который решает эту проблему - в режиме командной строки можно узнать об изменениях максимумов, а также сделать еще несколько полезных вещей.
После установки модуля можно вывести список доступных продуктов, которые есть на configmax.vmware.com:
Для конкретного продукта можно вывести список его версий/релизов:
Также для конкретной версии можно вывести список категорий максимумов:
С помощью командлета можно вывести все максимумы для конкретного продукта и определенной его версии:
Можно вывести все конфигурации в рамках заданной категории:
Ну и, наконец, с помощью командлета Compare-CfgMaxLimits можно сравнить максимумы конфигураций для разных версий одного продукта:
Как вы видите, тут есть поле CompareStatus, которое и говорит нам, новая ли эта настройка (New), измененная по сравнению с прошлым релизом (Modified), нетронутая (пусто) или удаленная (Deleted) в новой версии.
С помощью параметра New можно, например, вывести все новые настройки:
Параметр Modified выведет только отличающиеся максимумы конфигураций:
Ну а параметр Deleted выведет устаревшие настройки:
Ну и все вместе, без неизмененных значений:
Очень удобная штука, все это также можно экспортировать в формат CSV и сравнивать в Excel. Для этого можно использовать следующую команду:
PS > $product = Get-CfgMaxProduct -Name 'NSX-T Data Center'
PS > $releaseA = $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.0.0'
PS > $releaseB = $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.1.0'
PS > Compare-CfgMaxLimits -Product $product -Release $releaseA -CompareRelease $releaseB | Export-Csv -Path compare-status.csv -NoTypeInformation
Скачать данный PowerCLI сценарий с примерами вы можете по этой ссылке.
На днях на сайте проекта VMware Labs появилось очередное интересное обновление - новая версия гипервизора VMware ESXi Arm Edition 1.2 для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства).
Напомним, что о версии ESXi Arm Edition 1.1 мы писали вот тут, а здесь также рассказывали об установке этого гипервизора на платформу Raspberry Pi.
Давайте посмотрим, что нового в VMware ESXi Arm Edition 1.2:
Если у хоста нет датасторов, то datastore browsing отключен
Пофикшен отсутствующий параметр context_id для вызовов CPU_ON
Исправлена проблема с контроллером GICv2 (теперь SGI всегда включены и работают как устройства GIC-500)
Поддержка гостевых ОС на базе big-endian
Убраны требования/ограничения на initrd для ВМ без UEFI
В целом, все это технические фиксы - но обновить вашу тестовую лабу не помешает. Новая версия ESXi Arm встает только как свежая установка, обновление прошлых версий не поддерживается. Можно сохранить прошлые тома VMFS, выбрав опцию "Preserve VMFS", но машины надо будет перерегистрировать заново.
Скачать ESXi Arm Edition 1.2 можно по этой ссылке.
RSS
